home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Internet
/
Collection of Internet.iso
/
infosrvr
/
dev
/
www_talk.930
/
000121_mitra%pandora@…wood.mpk.ca.us _Mon Jun 8 22:23:03 1992.msg
< prev
next >
Wrap
Internet Message Format
|
1994-01-24
|
2KB
Return-Path: <mitra%pandora@fernwood.mpk.ca.us>
Received: from dxmint.cern.ch by nxoc01.cern.ch (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
id AA12313; Mon, 8 Jun 92 22:23:03 MET DST
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
id AA24770; Mon, 8 Jun 92 22:21:08 +0200
Received: by fernwood.mpk.ca.us; id AA13324; Mon, 8 Jun 92 13:16:50 -0700
From: mitra@pandora.sf.ca.us ()
X-Mailer: SCO System V Mail (version 3.2)
To: connolly@pixel.convex.com, wais-talk@think.com, www-talk@nxoc01.cern.ch
Subject: MIME for global hypertext
Date: Mon, 8 Jun 92 13:11:15 PDT
Message-Id: <9206081311.aa26440@pandora.sf.ca.us>
Dan,
Thanks for that proposal. I must admit to not having read the MIME RFC,
being mostly concerned with text rather than multimedia, so I wasnt
aware of the hypertext implications of it.
My question is on a fairly minor point of your document, you mention that
a MIME document typically consists of a content and then the pointers,
with the hypertext links being references to the pointers. In Wais, it
is quite possible to return part of a document (by byte position), and
if the pointers are part of the document itself then they may not be
returned at the time the user chooses to try and follow a link?
My concerns are around doing these things for users on low-speed (2400 baud)
modems. For them, protocols need to be easy to handle at slow speed, and
need to be meaningfull BEFORE the whole document has been received. As the
Internet extends out to more and more users beyond the high-speed links
currently assumed the need for protocol designers to consider those users
becomes more important.
- Mitra
------------------------------------------------------------------
Mitra - technical director, Pandora Systems
mitra@pandora.sf.ca.us